PD ROM 1

home *** CD-ROM | disk | FTP | other *** search

/ PD ROM 1 / PD ROM Volume I - Macintosh Software from BMUG (1988).iso / Electronic Messages / Delphi Digests / Delphi Vol. 3 / Delphi 3.11 < prev next >

Wrap

Text File | 1988-04-08 | 24.2 KB | 613 lines | [TEXT/ttxt]

15-Feb-87 07:12:19-PST,25335;000000000001 Return-Path: <SHULMAN@RED.RUTGERS.EDU> Received: from RED.RUTGERS.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Sun 15 Feb 87 07:11:46-PST Date: 15 Feb 87 10:05:51 EST From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU> Subject: Delphi Mac Digest V3 #11 To: Delphi-Digest-List: ; Message-ID: <12279252008.15.SHULMAN@RED.RUTGERS.EDU> Delphi Mac Digest Sunday, 15 February 1987 Volume 3 : Issue 11 Today's Topics: RE: draw-grab RE: LaserSpeed -> WOW (4 messages) Mac carrying cases System 3.3 and MacXL Lightspeed C and Macsbug symbols MPW C Doc and MPW Tools (4 messages) Re: Fortran Problem (2 messages) New HELP Resource type. (3 messages) Looking for Music Tutor Serious ROM 'feature' causes problems wi TMON with FPD (2 messages) Mac Zap v4.5 cricket draw Investigations into Memory Usage (3 messages) ---------------------------------------------------------------------- From: JDSCHNITZER Subject: RE: draw-grab (Re: Msg 17168) Date: 8-FEB-10:30: Mousing Around If it's a "library" of MacDraw files that you extract from, then definately try PictureBase. It's cheap and provides a DA PictureBase Retriever in addtion to the application. ------------------------------ From: BWD Subject: RE: LaserSpeed -> WOW (Re: Msg 17138) Date: 8-FEB-20:18: Business Mac I have been using it too and am also quite impressed. Unfortunately I use some fonts that were created with Fontographer which under normal circumstances are downloaded to the LaserWriter automatically. Using LaserSpeed no downloading occurs and the letters are displayed in one of the Laser Fonts, Helvetica I think. If that problem was fixed, I would use it all the time. Brian ------------------------------ From: STEVEMALLER Subject: RE: LaserSpeed -> WOW (Re: Msg 17182) Date: 10-FEB 18:03 Business Mac The documentation clearly states that you should use a "downloader" program to set up the LaserWriter first... Steve ------------------------------ From: MADMACS Subject: RE: LaserSpeed -> WOW (Re: Msg 17253) Date: 14-FEB 22:00 Business Mac Do you know if LaserSpeed works with PageMaker? (This is really for Steve Maller, I guess, since he started this thread, I believe). The beta 0.97?? version of SuperLaserSpool does _not_ fully. That is, it will print a PM file, but it uses the regular laserwriter driver and does not load Aldus Prep. The result is not acceptable. TO ALL: I am trying to advise a local small business as to the best spooler that they can buy that will work with (1) LaserWriter and a Linotronic (which uses the LW driver so should be ok) (2) Downloaded fonts (3) PageMaker, Word, Draw, Write, (especially PM) and is robust enough not to cause delays re-booting and recovering lost files. Any ideas? I would really appreciate your input. -Doug ------------------------------ From: MACINTOUCH Subject: RE: LaserSpeed -> WOW (Re: Msg 17308) Date: 14-FEB 22:03 Business Mac Doug, I'll jump in here, because I've been using LaserSpeed extensively. It works fine with PageMaker and all the other applications I've tried, although I haven't used downloaded fonts. It has been remarkably free from the bugs and annoyances we'd seen with previous laser spoolers. Ric Ford ------------------------------ From: HALL Subject: Mac carrying cases Date: 9-FEB-23:11: Hardware & Peripherals What's the best Mac carrying case around (Mac+, that is), how much does it cost, and where's the best place to get it? Is MacTotes still one of the better ones? Thanks, Brian ------------------------------ From: JSTIFF Subject: System 3.3 and MacXL Date: 10-FEB 01:41 Bugs & Features Well, Apple has finally done it to us die-hard MacXL (old Lisa) owners. The new System (Version 3.3 which is being distributed as part of the AppleShare file server software) will not work with the MacXL. This is even confirmed in the AppleShare manual! Does anyone have any insight into why the new system file cannot work with the MacXL or as to why Apple made this rather significant policy decision? ------------------------------ From: RCONGDON Subject: Lightspeed C and Macsbug symbols Date: 8-FEB-22:05: Programming Techniques I haven't seen this mentioned anywhere but it may be old news. If you have the "Macsbug Symbols" option checked for a project you only get symbols for functions that declare local variables. I understand that Macsbug symbols assume LINK/UNLK pairs and of course if the stack isn't used there's no need for the LINK/UNLK but it would be nice if they put the LINK/UNLK and the symbol in anyway (at least as an option). I know this is a minor quibble but it had me mystified for a bit... --bob "hoping for a REAL Lightspeed C debugger" congdon ------------------------------ From: JEFFS Subject: MPW C Doc and MPW Tools Date: 10-FEB 07:29 Macintosh Developers How come the MPW C manual doesn't describe the ToolLibs.o library and how to interface with it? How would I know what to do to write a tool in C? While looking through the MPW Pascal manual at work I found that *it* had a chapter on it. Are tools not supposed to be written in C? Does Apple/APDA *assume* that you will buy Pascal if you want to write a tool? Mind you, I have no intentions at this time to write a tool, I'm just upset that I can't if I wanted to using the documentation for MPW C I have at home. Jeff ------------------------------ From: BRECHER Subject: RE: MPW C Doc and MPW Tools (Re: Msg 1257) Date: 10-FEB 10:04 Macintosh Developers Don't panic. All the info (except maybe the cursor control stuff, which is going to change anyway) is there: in the Shell manual, and in the Standard Library chapter of the C manual. The C names don't have an "IE" prefix. Some of the stuff -- e.g., the argv/argc facility -- doesn't require special routines in C. ------------------------------ From: LOGICHACK Subject: RE: MPW C Doc and MPW Tools (Re: Msg 1258) Date: 13-FEB 01:53 Macintosh Developers What do you mean the cursor control stuff is going to change? Paul :) ------------------------------ From: BRECHER Subject: RE: MPW C Doc and MPW Tools (Re: Msg 1260) Date: 13-FEB 07:49 Macintosh Developers I mean it will be generalized to use resources, so you can design your own animated cursors. ------------------------------ From: Maloy Subject: Re: Fortran Problem Date: 11-FEB 11:15 Network Digests Re: A. REMY MALAN's FORTRAN problem The problem is not with the MS FORTRAN compiler, but with your code. You have a very subtle type mismatch error. If you select option "L" in MS FORTRAN 2.2 the next time you compile and examine the .LST file created, you'll note that FOOB is REAL*4 in the main program. You did not give a type to FOOB in module TEST, so REAL*4 is default. Unfortunately, FOOB is a REAL*8 function, as you know. The solution is to add the line "REAL*8 FOOB" in the main program (or modify the existing line to read "REAL*8 SUM,FOOB". As far as other compilers are concerned, they are probably acting the same way; it's just that converting from REAL*4 to REAL8* on some computers is simply a matter of adding some low order zeroes to make a total of 8 bytes. On the Mac, however, floating point arithmetic is performed using the proposed IEEE standard-- REAL*8 exponent fields are quite different than REAL*4 (see Appendix F in the MS FORTRAN manual) so that converting to double precision requires more than just "tacking on some zeroes." If the number you're converting isn't "really" REAL*4 you get some strange answers. For instance, when I realized the type mismatch, I uploaded your source file to a VAX computer and compiled with the /LIST option. FOOB was REAL*4 in the main program and REAL*8 in the FUNCTION, as expected. However, the program "appears" to be working correctly, as SUM = 25.0000 is printed. The type mismatch is still there, though, so I recompiled with a /G_FLOAT option on the VAX in hopes of causing the error. (G_FLOATing point is similar to REAL*8 on the Mac in that the exponent field is a different size than REAL*4.) As expected, the program printed a value other than 25.00: "SUM = 0.8476562500". I recommend explicitly typing every FUNCTION and VARIABLE in FORTRAN programs so that errors such as these won't occur. Bill Maloy 601-688-5572 ------------------------------ From: SPERRAZZA Subject: RE: Re: Fortran Problem (Re: Msg 17287) Date: 14-FEB 20:52 Network Digests MS-FORTRAN 3.31 (just recently superseded by 4.0) for MS-DOS machines did not support IMPLICIT NONE. Of course, it was in many other ways a lousy compiler, so this is not surprising. Io not know if 4.0 supports IMPLICIT NONE, as I have not yet upgraded. I agree that using it often means the saving of days of work during the testing phase. ------------------------------ From: PALAIS Subject: New HELP Resource type. Date: 12-FEB 11:43 Programming I have a suggestion for a new standard Resource Type, to be called HELP. Each resource of type HELP would be a single str255. Any number of HELP resources could be added to an application (or to the Resource Fork of a document). Each HELP resource would give help on using some feature of the appl ication, and would have a mnemonic name referring to that feature. An applicati on with HELP resources would put up a HELP menu on the menu bar using AddResMenu , so all the available HELP item names would appear as items on this menu. When a user chooses an item from this menu, a new HELP Manager would put up a dialog box displaying the associated HELP string. I see at least two advantages : % There would be a uniform user interface to on-line documentation. % It would become a piece of cake for developers to add basic documentation to new applications (using say REdit or ResEdit), SO THEY WOULD BE MORE LIKELY TO DO IT. The present method of attaching documentation to About... screens is very un Mac-like in my opinion...everyone does it differently, you donUt even know if its there if, like many users you donUt bother to pull down the Apple m enu, and it takes one more special effort on the part of a developer. ------------------------------ From: DONBYRD Subject: RE: New HELP Resource type. (Re: Msg 17262) Date: 13-FEB 06:58 Programming Interesting idea, and the should be a uniform way to invoke help. Regarding your particulars, I don't think an STR255 gives enough flexibility. I think Microsoft WORD already uses HELP resources for its Help facility, though I have no idea how. A friend of mine is developing an application that uses a scheme a lot like what you suggest, but he has way more than 255 characters per item, so he uses some other simple text representation, not STR255, and he has some typographic control in it as well. ------------------------------ From: PEABO Subject: RE: New HELP Resource type. (Re: Msg 17262) Date: 12-FEB 12:35 Programming It's a good idea except that one Str255 probably isn't enough. Something I've been thinking of doing is to define a STR# resource to match each dialog I have in my program, and correlate the strings in the STR# with the item numbers in the dialog. I haven't pursued it too far though; it's just a thought about ho to do context sensitive help. peter ------------------------------ From: MACINTOUCH Subject: Looking for Music Tutor (Re: Msg 17254) Date: 12-FEB 22:55 Network Digests To: Wahl.ES@Xerox.COM Subject: Looking for Music Tutor Listen, from Imaga (PO Box 638, Middletown, CT 06457; 203-347-5909) is an excellent ear training program. It lists for $69, and unfortunately, is copy perverted. Ric Ford, "MacInTouch" newsletter ------------------------------ From: PEABO Subject: Serious ROM 'feature' causes problems wi (Re: Msg 17270) Date: 12-FEB 23:08 Network Digests >Date: Tue, 10 Feb 87 18:07:41 PST >From: <DAVEG@slacvm.bitnet> >Reply-to: DAVEG%SLACVM.BITNET@forsythe.stanford.edu >Subject: Serious ROM 'feature' causes problems with multiple stacks ... > OK, so what I find is that at least one place in the ROM takes the >current value of the stack pointer, subtracts the value at HEAPEND (to >'determine' the amount of 'free' space remaining on the stack) and if it >is large enough, uses that space for something!!!!! In the above multiple >stack scenario one finds that if you are using (for example) the stack >which is the highest in memory, this ROM routine will calculate lots of >'free' space between SP and HeapEnd and use it! This clobbers my other >stacks quite nicely. ... > I know this is longwinded and hopefully not too confusing to those >who are familar with programming the Mac. Basically I am hoping (A) to >get some hints about how others have implemented multiple stacks and (B) >ideas for workarounds and (C) does anyone else think that calculating >free stack space this way is goofy or is it just me? This strategy is good programming style, if you ask me. (1) you told the ROM it was OK to use the space (because the area between heapend and current SP is the available stack space), (2) it is a way to program an algorithm which probably functions when tight on storage, but which functions faster when it can save more information about what it's doing (lots of graphics algorithms are like that), and (3) it uses space in a way that doesn't cause long term problems by purging stuff from the heap, which would be the other place it could get temporary storage. I think what you are going to have to do is to diddle the heap when you switch stacks. If you are reasonably lucky, this will only require changing a few words here and there. Allocate your extra stacks in the original heap and do MoveHHi on each one and lock it. Now you have the stacks allocated in the correct place in memory and all you have to do is adjust the heap zone so that heapend always points to the bottom of the active stack and the heap is always self-consistent, including whichever locked blocks happen to be below the stack. The ones above the stack are protected by virtue of looking like legitimate stack allocations. Your biggest difficulty may be in proving that whatever you have to diddle is fully described by a published interface. I suspect that it is. As a byproduct of this, you can arrange the sniffer to give you a bomb if it discovers one of your stacks has grown into the one below it. peter "In any context, half of all references PEABO @ DELPHI are local and half are global." ------------------------------ From: DDUNHAM Subject: TMON with FPD Date: 12-FEB 21:25 Tools for Developers Yay! I finally got the "experimental version" of "TMON - Universal," which runs on a Radius FPD (and presumably other size screens, as well as 68020s). Contact ICOM Simulations if you need this. ------------------------------ From: LOGICHACK Subject: RE: TMON with FPD (Re: Msg 1259) Date: 13-FEB 01:54 Tools for Developers How does it use the screen? Do you have the option of using the Mac Screen for debugging? Paul :) ------------------------------ From: IVANOVIC Subject: Mac Zap v4.5 Date: 14-FEB 00:55 Programming I just got today my upgrade to v4.5 of Mac Zap -- and I like what I've got. The primary reason I upgraded was to be able to read physical blocks on my hard disk, and that I can do. Everything seems to work. The windows not updating perfectly has been fixed, and in general, a good program has been made to work better. There is SCSI support for finding lost files (deleted ones) and for displaying the volume allocation map graphically. The mouse turns into a cross hair when over the display, and the block number is displayed. If a file is selected, then only it's allocated blocks are displayed. Pretty sexy, if you ask me. I also got Les Herbst's "Macintosh Floppy and Hard Disk MFS and HFS Disk Structures" book. It's 61 pages long and it contains information and discussion about disks and servers. Nothing exceptionally new, but it's all in one place and organized. Worth $15? Yeah, maybe. The discussion in the Fedit+ manual is better in many ways. -- Vladimir ------------------------------ From: JIMH Subject: cricket draw Date: 14-FEB 01:10 Business Mac All you who have been having problems with cricket draw 1.1 will be mailed out next week to all registered owners. they assure me all major bugs are fixed! jim ------------------------------ From: IVANOVIC Subject: Investigations into Memory Usage Date: 14-FEB 03:06 Programming I spent some time trying to figure out who was using what in memory because I like to run with lots of specialized code, like debuggers (TMON), macro facilities (Tempo), disk caches (TurboCharger), pseudo-multitasking (Switcher), etc. I was having problems, so I tried to figure out who was stepping on whose toes. Appended are my results. There are gaps in my knowledge. For example, I have NO idea how TurboCharger works. (I use it without Quick Quit and it is better behaved.) Others are encouraged to contribute what they know. ........................................................................... Mac+ Memory Usage * Base Configuration + System 3.2 from HD20 Startup diskette. + 128K v3 ROM + 2MB memory by Levco clip-on. + Boot Block Version = $12 + Sound buffer size = $300 + Screen buffer size = $5600 + Jump table and application parameter size = $238 + Application globals and QuickDraw globals size = $D56 + Stack size = $80A2 + Application heap size = $1E 4BD0 + System heap size = $B700 * Apple RAM cache + Selected size = 128K + Installs itself in high memory directly below the screen buffer. + Modifies - Lowers BufPtr by the size of the cache. + Notes - Not a "write-through" cache; flushed only when - another block replaces it (LRU) - a volume flush is done - the application terminates. - Code loaded above BufPtr by INIT 35 resource - Cannot be removed except by reboot. - Cannot be installed except at boot time, i.e. Control panel must be set prior to boot. - Limited choice of sizes. From 32K to 1.5M with increments of 32K for 32-128K, 64K for 128-512K, 128K for 512-1M and 512K to 1.5M. - See Tech Note #81 for details. * System Heap Size + Configured by modifying an entry in the boot disk's boot block. + Version 1.2 of the Boot Data has the 512K system heap size at (indicated) $C000 and the Boot Block Version=$12. Actual size is $B700. + Boot Block Version from $12 to $15 only. - System heap grows by $900 to value stated in boot block. - The application heap shrinks by $800 and gets bumped up by the growing system heap. + Boot Block Version=$15 and System Heap Size=$D000. - Corresponding increase in System Heap. ApplZone increased by appropriate amount. + Same for System Heap Size=$E000. + Modifies - For change to Boot Block Version, ApplZone upped by $900 and HeapEnd upped by $100. - For change in system heap size in boot block, equal change in ApplZone. * RAMSafe 1.1 + Selected size = 1024K (= 1 MB) + Installs itself in high memory, but leaves the sound and screen buffers where they are. + MemTop and BufPtr are set equal to 1MB. + Modifies - BufPtr lowered by selected size of (the RAM disk minus the size of the sound and screen buffers). $1F A700 - ($10 0000 - $30 - $5600) = $F FD30 - MemTop lowered by the selected size. + Notes - Has no removal option. - Shutdown-proof (uses a modified PROM which prevents clearing of memory on reboot), but not powerdown-proof. - The size of the area reserved is the selected size minus the size of the sound and screen buffers, i.e. $10 0000 - ( $300 + $5600) = $F A700 = 1001K. - The RAM disk itself indicates a size of 975K plus 8K for the desktop, or 983K total. - Only 5 sizes to choose from: 512K 768K 1024K 1280K and 1536K. * MaxRAM 2.3 + Selected size = 1024K + Installs itself in high memory below the sound and screen buffers. + Modifies - BufPtr lowered by the selected size plus an extra 8 bytes. ($10 0000 + $8 = $10 0008) + Notes - RAM disk is 997K with 8K used = 1005K. + Remove returns everything to its previous state. + Size selection is has a 1K adjustablity. * RAMStart 1.3 + Selected size = 1024K + Installs itself in high memory just below the sound and screen buffers. + Modifies - BufPtr is lowered by 1024K exactly. + Notes - RAM disk has 1000K available with 8K used. Hence 16K is used for the driver and data. - Size is adjustable in 1K increments. - Removal restores previous state. * TurboCharger 2.0 Rev D + Installs itself in memory somewhere somehow. + Modifies - BufPtr - Definitions - Memory left over = modified BufPtr - size selected - 512K size -> $8 5470 - $17 5290 used = 1492K - 768K size -> $C 5580 - $13 5180 used = 1236K - 1024K size -> $10 4C40 - $F 5AC0 used = 982K - 1280K size -> $14 5590 - $B 5170 used = 724K - turned off -> $1F A700 = 2025K + Notes - Auto Buffer Sizing was turned off - Removal returns values to normal state. - The addresses below BufPtr are the normal distance apart, e.g. the size of the system stack is always $80A2. - In the 512K case, the application limit and the application heap end were within $4C of each other. - A choice of 32K either crashes or hangs the Mac. * Tempo 1.1b + Installs itself in high memory below the screen and sound buffers. Jillions of resources are added to the system file. + Modifies - BufPtr is lowered by $1B1E. + Notes - Removal does not adjust BufPtr, but does remove the resources from the system file. - Uses at least 1052 bytes of system heap. - Installs 78 167 bytes into the system file. Removal leaves 1452 bytes behind (vestigial resources.) * MacsBug 5.2 + Installs itself in high memory. + See "Inside Switcher" for details. + Modifies - BufPtr - lowers it by 44 940 bytes ($AF8C) * TMON 2.585 + Can be installed either in the system heap or in high memory. + Modifies - [In system heap] HeapEnd increases by size of (TMON - 4 bytes). - [In high memory] BufPtr is lowered by size of (TMON - 11 bytes). + Notes - Maximum TMON size with EUA 685 is $12E2A or 77 354 bytes as calculated by TMON's Monitor size menu item. - If both TMON and MacsBug are installed, TMON wins. * Switcher 5.0.1 + See "Inside Switcher" for details ............................................................................ Worse than leaving out information is presenting incorrect information. Please DO correct any errors. Many, many thanks to Julian Vrieslander (eacj%batcomputer@cu-arpa.cs.cornell.) *that's ".edu" for his excellent MacDraw Mac+ Memory Map. -- Vladimir ------------------------------ From: PEABO Subject: RE: Investigations into Memory Usage (Re: Msg 17291) Date: 14-FEB 04:34 Programming Thanks for the investigation! Because of the problems with Quick Quit, I don't use TurboCharger on my hard disk system. I use it on my Mac 512K Floppy system all the time though, and it works pretty well for the limited applications I use it with (MacTerminal and DA's mostly). peter ------------------------------ From: MACINTOUCH Subject: RE: Investigations into Memory Usage (Re: Msg 17294) Date: 14-FEB 11:24 Programming I'm using Turbo with the 2.5MB Mac Plus and the DataFrame hard disk, and, for me, it's a very efficient way to use the extra RAM. I've turned off Quick Quit and I'm careful using it with TOPS, but it's been working fine with a variety of normal word processing, graphics, and telecomm. applications. Ric ------------------------------ End of Delphi Mac Digest ************************ -------